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Abstract 

The  complexity  of  designing  and  acquiring  weapons  systems  continues  to  increase  due  to 
highly  integrated  system  architectures,  rapid  technology  evolution,  and  emergence  of  highly 
diverse  warfare  missions.  The  imperatives  of  system-of-systems  (SoS)  integration  and 
interoperability  (l&l)  further  complicate  the  system  acquisition  process.  In  order  to  deliver 
highly  integrated  and  interoperable  systems,  the  acquisition  process  itself  needs  higher  levels 
of  integration. 

Navy  Systems  Commands  are  exploring  the  need  to  transform  the  acquisition  process  in 
integrated  warfare-driven  management,  interoperable  warfare  mission  analysis,  and  complex 
design-driven  engineering  workflows.  These  integrated  workflows  are  embodied  in  the 
acquisition  roles  of  a  Lead  System  Integrator  (LSI).  In  our  previous  papers,  we  described  (1) 
the  roles  and  attributes  of  the  LSI  and,  (2)  the  concept  of  how  System  Definition-Enabled 
Acquisition  (SDEA)  can  support  the  systems  engineering  imperatives  of  acquisition  of 
complex  systems. 

In  this  paper,  we  extend  our  previous  work  to  discuss  emerging  concepts  being  explored  in  a 
Navy  Systems  Command  where  aggressive  transformational  goals  in  warfare  mission-driven 
acquisition  management  processes  can  be  supported  by  our  previously  described  design- 
driven  engineering  processes  (SDEA).  The  union  of  these  two  process  transformations  is 
essential  to  enabling  an  environment  where  the  Government  acquisition  organization  can 
succeed  as  the  LSI  to  rapidly  deliver  complex  systems  while  achieving  demanding  l&l  goals 
and  objectives 

Introduction 

At  the  2012  and  2013  acquisition  conferences,  the  authors  described  (1)  the  roles 
and  attributes  of  the  LSI  (Montgomery,  2012)  and,  (2)  the  concept  of  how  System  Definition- 
Enabled  Acquisition  (SDEA)  can  support  the  systems  engineering  imperatives  of  acquisition 
of  complex  systems  (Montgomery,  2013).  Since  those  last  two  conferences,  two  significant 
changes  have  begun  at  NAVAIR  which  has  set  the  stage  for  the  continuation  of  the 
application  of  the  previously  discussed  SDEA  principles  and  practices.  The  first  is  that 
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NAVAIR  has  started  the  transition  to  becoming  an  LSI  as  has  been  proposed  by  many 
(Grasso,  2007)  over  the  last  several  years.  One  such  program  is  executing  Governmental 
LSI  responsibilities  by  designing,  developing,  and  integrating  the  mission  communication 
system  (MCS)  in  one  of  its  new  helicopter  programs.  Another  program  is  executing  the 
entire  LSI  spectrum  of  responsibilities  on  a  new  Unmanned  Air  Vehicle  (UAV)  program. 

The  second  key  transformation  underway  at  NAVAIR  is  an  aggressive  concept  of 
transforming  to  a  mission-driven  acquisition  management  process.  In  order  to  deliver  the 
mission  capability  that  is  needed  in  the  fleet,  an  emergent  mission-centric  approach  defining 
needed  operational  capability  is  being  pursued.  This  Integrated  Warfare  Concept  (IWC)  is 
beginning  to  heavily  rely  on  the  understanding  and  use  of  Model  Based  System  Engineering 
(MBSE)  methodologies  and  tools  to  aide  in  the  accomplishment  of  this  goal.  The  goal  of  the 
IWC  is  to  understand  and  map  all  of  the  systems  required  to  accomplish  a  specific  capability 
to  all  of  the  different  platforms  and  programs  of  records  (PORs)  that  play  a  part  in  it.  This 
requires  a  thorough  understanding  of  the  operational  and  mission-level  requirements  to  be 
allocated  to  the  various  programs.  This  IWC  process  is  currently  exploring  an  extensive  use 
of  MBSE  to  accomplish  this  mission  decomposition  and  allocation  to  PORs.  This  creates  an 
urgent  need  for  the  PORs  to  develop  a  method  to  directly  interface  to  that  model-driven  IWC 
input  and  map  their  outputs  to  it  in  order  to  demonstrate  that  the  POR  system  level 
requirements  can  fulfill  the  IWC  mission-level  requirements. 


LSI,  SoS,  Models 
Operational  &  Mission  Reqmts 


POR 


tt 


Workforce,  Tools,  Training 
Documents,  Process,  System  Reqmts 


Figure  1 .  Merger  of  New  Roles  and  Process  With  Existing  Process 

These  new  concepts  are  depicted  in  Figure  1  and  are  converging  and  serving  as  a 
forcing  function  for  NAVAIR  to  develop  a  more  robust  use  of  tools  that  will  enable  the 
programs  to  capture  and  demonstrate  the  additional  information  required  to  perform  in  these 
enhanced  roles.  The  current  POR  engineering  process  is  a  highly  document-driven  process 
that  relies  heavily  on  teams  of  seasoned  experts  to  analyze  engineering  and  acquisition 
documents  to  determine  design  readiness.  Because  of  these  imperatives  to  align  mission- 
driven  acquisition  to  design-driven  engineering,  the  authors  have  been  pursuing  the  further 
development  of  the  SDEA  concept  previously  introduced.  We  believe  that  the  use  of  the 
SDEA  concept  will  be  the  conduit  which  will  allow  NAVAIR  to  be  successful  on  both  of  the 
above  ventures,  to  become  the  program  LSI,  and  to  demonstrate  the  ability  to  integrate  with 
and  ultimately  acquire  the  warfighter  capabilities  dictated  from  the  top  down  IWC  process. 

Problem  Definition  and  Research  Questions 

The  imperatives  for  NAVAIR  to  perform  more  of  the  LSI  role  (Young,  2010)  and  the 
advent  of  the  IWC  (Dunaway,  2013)  drive  the  need  for  a  new  approach  that  is  less 
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workforce-intensive  and  less  document-driven  approach  that  is  in  use  today.  The  acquisition 
of  complex  system-of-systems  (SoS)  envisioned  in  the  model-driven  IWC  process  requires 
revised  engineering  methods,  practices,  and  principles  that  ensure  capabilities  can  be  met 
and  equip  the  NAVAIR  workforce  with  the  data  and  knowledge  required  to  perform  the 
acquisition  and  LSI  tasks.  This  paper  will  expand  the  on  the  concept  of  SDEA  described  in 
earlier  conferences  and  investigate  how  it  could  help  NAVAIR  succeed  in  performing  their 
new  environment. 

Problem  Statement: 

The  DoD  does  not  have  adequate  Systems  Engineering  (SE)  methods,  processes, 
workflows,  and/or  tools  that  support  the  expansive  Governmental  role  of  the  LSI  in  major 
weapons  systems  acquisitions  or  the  ability  to  integrate  with  and  develop  the  programs  of 
record  identified  through  the  top-down  IWC  analysis  process. 

Research  Questions: 

•  How  can  the  use  of  MBSE  tools  be  applied  to  aid  the  program  office  in 
assuming  more  of  the  LSI  role? 

•  What  are  the  varied  SE  methods  and  practices  in  use  across  NAVAIR 
today.? 

•  What  is  a  model  of  the  NAVAIR  acquisition  process  in  use  today? 

•  What  is  an  integrated  framework  of  tools  and  MBSE  methods  that  reflects  the 
artifacts  needed  to  integrate  with  the  IWC  and  perform  LSI  roles? 

•  How  can  this  new  Model  Based  Acquisition  Framework  (MBAF)  be  applied  to 
simulate  or  optimize  process  variations  on  programs? 

LSI  Roles  and  Responsibilities 

A  review  of  the  roles  and  responsibilities  required  of  a  government  LSI  was 
conducted  to  determine  where  the  application  of  SDEA  and  other  tools  may  be  most 
beneficial.  The  below  list  of  System  Engineering  and  Program  Management  skills 
was  compiled  with  the  help  of  several  senior  leaders  from  NAVAIR.  The  bold 
comments  are  areas  where  the  increased  use  of  SDEA  and  other  MBSE  tools  with 
their  data  driven  definition  and  the  increased  visualization  should  support. 

Systems  Engineering  LSI  skills  emerging  at  NAVAIR: 

•  Conduct  analysis  of  broad  system  requirements  and  identify  inter¬ 
dependencies 

•  Perform  the  SoS  LSI  role  and  deriving  trade  space  to  be  held  at  mission 
level 

•  Ensuring  SoS  optimization  and  cross  platform  interoperability  that  provide 
traceability  to  mission  level  requirements. 

•  Define  and  control  system  interfaces  consistent  with  the  overall  systems 
architecture — both  in  the  SoS  operational  architecture,  and  in  the  related  SoS 
views — to  ensure  required  Mission  level  capability  is  delivered  through 
deliberate  system  development  as  part  of  required  SoS  functionality. 

•  Develop  the  System  Architecture  must  be  developed  by  the  Government 
(may  not  be  outsourced)  and  also  done  without  contracting  for  support  with 
the  Prime  contractor  or  any  major  subsystem  vendor.  Government  ownership 
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of  system-level  architectures  reduces  possibility  of  proprietary  or  non- 
compliant  contractor-specific  architectures 

•  Control  the  technical  trade  space  through  preliminary  design,  to  include 
budget,  requirements,  and  schedule  tradeoffs 

•  Act  as  the  LSI  role  up  to  Milestone  B  to  control  the  trade  space  with  regard 
to  issues  impacting  the  System  Architecture. 

Program  Management  LSI  skills  emerging  at  NAVAIR: 

•  Conducting  work  where  precedents  are  inadequate  or  controversial. 

•  Developing  project  schedules  and  resource  estimates  across  multi- 
disciplined  technical  teams. 

•  Establishing  and  managing  broad  system  processes  that  align 
requirements  and  interdependencies  across  program  boundaries. 

•  Interacting  between  disciplines  such  as  contracting,  legislative, 
RDT&E,  Logistics,  and  budgetary  processes  within  the  DoD 
Acquisition  Decision  Support  System 

•  Navigating  a  wide  range  of  non-engineering,  non-scientific  info  (FAR, 
policies,  directives,  instructions,  contracting,  admin  processes). 

•  Controlling  the  trade  space  through  preliminary  design,  to  include 

budget,  requirements,  and  schedule  tradeoffs 

•  Maintaining  traceability  of  systems  integration  requirements  to  higher 
level  mission  objectives. 

•  Representing  the  system  command  at  national  technical  reviews 

•  Formalizing  Program  Management  structure  for  CDD(s)  that  drive 
system  requirements  spanning  multiple  PEOs. 

•  Exercising  technical  authority.  Government  is  the  integrator  of  major 
subsystems  in  the  architecture  as  part  of  performing  the  LSI  role. 

This  is  a  good  point  to  review  what  is  meant  by  SDEA  and  what  a  model  based 
acquisition  framework  might  look  like  that  would  help  illustrate  why  the  authors  believe  that 
this  approach  is  needed  to  aide  NAVAIR  or  any  acquirer  to  accomplish  the  SDEA  the 
highlighted  areas  above. 

System  Definition  Enabled  Acquisition 

Top-Level  Concept 

The  original  SDEA  concept  has  been  expanded  since  we  first  introduced  it 
(Montgomery,  2012).  The  Model  Based  Acquisition  Framework  (MBAF)  description  below 
will  demonstrate  the  process.  There  are  two  major  pieces  to  the  proposed  Model  Based 
Acquisition  Framework  (MBAF),  a  System  Definition  Enabled  Acquisition  (SDEA)  process 
and  a  Business  Process  Model  (BPM;  see  Figure  2). 


MSi 

TMlBWlTt*  MH 


ACQUISITION  RESEARCH  PROGRAM: 
CREATING  SYNERGY  FOR  INFORMED  CHANGE 


-56- 


MBAF 


|  Model  Based  Acquisition  Framework  [ 


SDEA 

BPM 

System  Definition  Enabled  Acquisition 

Business  Process  Model 

MDD 


MBSE 


MBSI 


Model  HProcess 


Model  Driven 


"sign  |  ^^Model  Based ~SE~  ^^^ModeHBasedsFI 


Figure  2.  Proposed  Model  Based  Acquisition  Framework 

System  Definition  Enabled  Acquisition  (SDEA) 

The  SDEA  concept  starts  with  a  foundational  model  comprised  of  a  deep 
understanding  of  the  CONOPS,  requirements,  and  architecture  to  serve  as  the  basis  for 
understanding  and  documenting  what  the  system  needs  to  perform.  It  can  be  a  challenge  to 
describe  in  just  a  few  scenarios/use-cases  and  numerous  requirements  (“shall”)  statements 
the  entirety  of  the  complex  systems  that  are  being  developed  today.  The  use  of  models  in 
the  early  stages  of  a  program’s  life  could  allow  for  all  to  get  a  better  mutual  understanding  of 
the  requirements  “shall”  statements  that  are  often  put  out  for  contractors  to  bid  on.  The  Chief 
engineer  for  the  system  and  software  division  at  the  Jet  propulsion  lab  summed  it  up  when 
he  stated  that  “the  benefit  of  formal  modeling  is  that  we  can  finally  stop  being  ambiguous 
and  say  exactly  what  we  mean”  (Delp,  2012). 

This  early  foundational,  system  definition  model  would  serve  as  the  tool  from  which 
requirements  could  be  vetted,  specifications  could  be  created,  and  interfaces  examined  and 
defined  and  ultimately  would  become  part  of  the  system  proposal  from  which  the  rest  of  the 
acquisition  process  would  build.  This  process,  shown  in  Figure  3,  would  provide  much  more 
insight  for  the  designer  as  they  would  be  able  to  “see”  some  of  the  interaction  and  obtain  a 
much  clearer  “picture”  of  what  was  required  than  the  normal  requirements  “shall” 
statements,  use-cases,  and  CONOPS  alone.  This  triad  of  integrated,  data-driven  information 
forms  a  strong  foundation  and  platform  for  the  builder  to  explore  the  relationships  among 
requirements  and  to  answer  the  myriad  of  questions  that  would  not  sufficiently  or  easily  be 
answered  using  a  handful  of  “shall”  statements  and  walking  through  use-case/CONOPS, 
alone. 


This  system  model  can  look  up  at  the  mission-level  model  and  requirements  coming 
down  from  the  IWC  process  and  it  can  demonstrate  that  the  system  design  can  fulfill  those 
mission  requirements.  This  initial  system  model  could  be  put  in  the  request  for  proposal 
(RFP)  and  contractors  could  bid  to  the  model  and  ultimately  be  required  to  demonstrate  that 
their  proposal  met  the  requirements  by  joining  with  the  model.  This  insight  itself  has  the 
potential  to  reduce  some  of  the  time  that  normally  takes  place  when  a  builder  sorts  out  the 
true  meaning  of  the  proposal  they  received  as  they  proceed  through  their  requirements 
derivation  and  proposal  process.  This  new  larger  model  would  continue  to  grow  in  detail  and 
design  fidelity  as  the  system  matured  throughout  the  design  cycle  and  would  ultimately 
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become  a  complete  system  model  that  would  then  include  the  interfaces  and  other  critical 
element  required  for  successful  system  integration. 


Figure  3.  System  Definition  Enabled  Acquisition  Overview 

(Montgomery,  2013) 

SDEA  can  be  visualized  in  three  sections,  Model  Driven  Design  (MDD),  Model 
Based  System  Engineering  (MBSE)  and  finally  Model  Based  System  Integration  (MBSI). 
Some  may  look  at  these  as  very  similar  or  even  the  same,  but  they  are  broken  out  in  Figure 
4,  as  they  will  be  referred  to  in  this  section. 


Figure  4.  Levels  of  Model  Based  Engineering 
Model  Driven  Design  (MDD) 

The  Model  Driven  Design  is  the  beginning  of  the  SDEA  concept.  Ultimately,  it  is  the 
model  that  is  created  combining  the  architecture,  both  functional  and  physical,  of  the  system 
that  is  captured  through  decomposing  the  requirements  and  fully  understanding  the 
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CONOPS  of  the  system.  This  phase  is  shown  in  Figure  4  as  continuing  through  preliminary 
design  as  this  early  model  could  ultimately  be  put  out  for  bid.  The  contractors  would  add  on 
to  this  early  model  to  demonstrate  that  their  proposal  met  the  requirements  and  was  able  to 
interact  with  the  proposed  concept.  This  generally  gets  the  program  to  an  early  preliminary 
design  review  (PDR)  just  prior  to  contract  award. 

Model-Based  System  Engineering  (MBSE) 

The  MBSE  phase  as  depicted  in  Figure  4  is  the  continuation  of  the  original  model  as 
the  system  design  is  further  defined  and  refined.  This  is  the  stage  when  the  addition  of  some 
of  the  other  physical  models  would  start  be  added  to  the  system  model  that  would  be  utilized 
as  the  system  matures  through  the  critical  design,  or  “build-to”  phase,  into  the  early 
verification  phase.  During  this  phase  it  is  likely  that  the  contractor,  or  sub-contractors,  would 
be  creating  or  adding  on  to  the  base  model.  The  ultimate  goal  of  this  approach  is  to  have  a 
full  model  of  the  system  at  the  end  of  design. 

Model-Based  System  Integration  (MBSI) 

System  integration  is  often  thought  of  at  the  end  of  the  program  but  in  reality  it  starts 
at  the  beginning.  Integrating  integration  and  qualification  strategies  early  in  the  system 
design  model  is  the  essence  of  MBSI.  How  something  integrates  and  how  it  can  be  tested 
should  be  one  of  the  initial  concerns  as  a  program  is  being  built.  The  use  of  a  model  should 
allow  for  some  early  looks  across  the  standard  systems  engineering  process  model  (SE  “V”) 
to  see  how  the  concepts  are  validated  down  to  how  individual  components  can  be  integrated 
and  validated.  In  essence,  as  depicted  in  Figure  4,  this  also  starts  with  the  initial  model 
created  by  the  government  customer.  A  model  that  has  the  fidelity  to  look  across  the 
systems  engineering  “V”  would  allow  for  one  to  gain  confidence  in  the  design,  understand  or 
eliminate  risks  earlier  in  the  program,  and  lead  to  some  early  prototypes  when  the 
associated  risks  become  acceptable.  The  ability  to  get  to  production  earlier  is  desired  during 
rapid  development  initiatives  and  in  general,  as  time  often  equals  money. 

Business  Process  Model  (BPM) 

Finally,  this  model-based  acquisition  approach  needs  to  be  coupled  with  an 
appropriate  business  process  that  will  be  able  to  take  full  advantage  of  the  new 
methodology  and  capture  the  savings.  The  authors  are  seeking  to  determine  if  the  current 
acquisition  process  can  be  modeled  using  a  data-driven  modeling  tool  such  that  the  major 
acquisition  activities  are  captured  as  functions  and  the  major  outputs  of  these  activities,  the 
artifacts,  are  captured  as  outputs  from  the  functions.  Once  this  model  is  created  and  a 
detailed  list  of  artifacts  is  produced  they  can  be  examined  to  determine  what  possible  model 
based  tools  could  or  are  currently  used  to  produce  them,  which  when  combined  would  form 
a  Model  Based  Acquisition  Framework.  There  are  numerous  other  potential  uses  that  we  will 
discuss  further  as  we  describe  the  initial  steps  undertaken  on  this  research.  This  effort  will 
be  described  in  the  remainder  of  this  article. 

SE  Methods  and  Practices 

Although  the  DoD  5000.02  has  a  scripted  process  or  series  of  events  that  need  to  be 
followed  to  produce  systems  it  was  quickly  discovered  that  the  process  to  perform  these 
steps  is  far  less  scripted  or  documented.  The  authors  have  settled  in  on  two  main  source 
documents  to  provide  insight  into  the  NAVAIR  process,  the  first  being  the  International 
Standard  I  SO/I  EC  15288  Systems  and  Software  Engineering-Systems  Life  Cycle  Processes 
and  the  second  being  the  Naval  Systems  Engineering  Guide.  From  these  documents, 
experience  from  industry  and  SMEs  at  NAVAIR,  we  are  capturing  and  documenting  the 
NAVAIR  process  and  using  it  to  create  the  data  model.  An  early  observation  is  that  even 
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these  documents  do  not  clearly  describe  a  repeatable  process  that  novice  engineers  could 
follow  without  moderate  assistance  from  experienced  engineers. 

Acquisition  Process  Model 

The  process  derived  from  the  above  documents  is  then  being  entered  into  an  MBSE 
system  design  modeling  tool  (Vitech  Corporation’s  CORE®)  to  form  the  basis  of  the  data- 
driven  model.  Figure  5  shows  a  representation  of  the  decomposed  function  Define  and 
Derive  Requirements.  As  mentioned  previously,  these  derived  sub-functions  are  a 
combination  of  information  from  ISO  15288,  Navy  System  Engineering  Guide,  Industry  and 
NAVAIR  SME’s.  It  is  crucial  in  this  initial  model  to  accurately  capture  the  NAVAIR  process  in 
use  today  as  they  would  like  to  use  this  model  to  what-if  the  current  process  to  examine 
potential  areas  for  efficiencies  and  policy  modifications. 


Figure  5.  Diagram  of  Define  and  Derive  Requirements  Function 

Model  Based  Acquisition  Framework  and  Products 

The  artifacts  or  products  that  we  started  mapping  were  the  tier  3  artifacts  from 
NAVAIRs  Systems  Engineering  Technical  Review  Process  (SETR)  checklist.  These  artifacts 
are  the  defined  products  associated  with  the  entry  into  or  exit  from  a  key  SETR  event. 

These  served  as  the  reference  to  ensure  that  the  process  and  artifacts  captured  aligned  as 
closely  as  possible  with  the  true  as-is  process  in  use  today.  The  original  list  of  tier  3  artifacts 
contained  326  items,  many  of  which  were  deemed  outside  the  systems  engineering  effort 
and  were  discarded.  After  some  scrubbing  and  agreement  the  final  list  contained  93  artifacts 
that  were  deemed  to  have  a  direct  or  secondary  impact  on  systems  engineering.  After 
starting  the  process  mapping  and  decomposition  it  quickly  became  evident  that  the  number 
of  artifacts  would  increase  as  some  of  the  artifacts  were  repeated  at  different  levels  of 
maturity,  and  some  applied  to  multiple  different  engineering  domains  (for  example,  perform 
engineering  analysis).  These  needed  to  be  further  defined  to  be  specific  enough  to  gain  a 
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thorough  understanding  of  the  artifacts  for  further  analysis.  As  mentioned,  the  artifacts  from 
this  model  form  the  requirements  or  basis  for  the  framework  of  the  MBSE  tools  and 
methods.  Physical  and  data  models  that  produce  them  will  be  sought  to  create  a  Model 
Based  Acquisition  Framework  (MBAF).  With  this  in  mind  it  was  obvious  that  clarity  in  these 
artifacts  was  very  important.  Figure  6  is  an  example  of  the  data  flow  from  the  function  Define 
and  Derive  Requirements. 

Another  area  of  interest  was  to  identify  the  need  or  specific  use  of  the  artifacts 
produced.  Artifacts  are  produced  for  several  reasons  not  all  are  directly  related  to  the  design 
of  the  system.  For  example,  some  are  produced  for  design  integrity  and  flight  clearance 
while  others  are  for  statutory  or  regulatory  requirements.  The  use  of  these  artifacts  provides 
insight  into  why  and  whom  they  are  created  for  and  provide  NAVAIR  with  potential  areas  for 
process  improvements. 


Figure  6.  Data  Flow  Diagrams 
Model  Validation  and  Uses 

The  final  phase  in  the  process  is  to  validate  the  model  by  using  it  on  a  program  and 
then  to  begin  the  model/process  optimization  process.  It  is  the  current  intent  that  NAVAIR 
will  use  the  model  to  run  simulations  on  process  changes  in  an  attempt  to  make 
improvements  in  and  optimize  their  acquisition  process.  The  model  should  help  tailor  the 
process  for  systems  that  may  not  require  all  of  the  elements  in  the  acquisition  timeline. 
Currently,  all  systems,  no  matter  how  large  or  small,  start  with  the  same  process  and  have 
to  make  determinations  on  how  to  tailor  the  process  to  fit  their  program.  This  detailed  model 
is  envisioned  to  provide  insight  into  that  tailoring  and  also  determine  the  required  artifacts.  In 
the  realm  of  IWC  and  LSI,  the  system  models  should  provide  insight  into  the  capabilities  and 
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interfaces  of  the  systems  that  are  not  easily  captured  without  a  defined  modeling 
environment. 

There  are  multiple  other  areas  that  a  model  with  these  attributes  may  provide 
insights.  The  model  will  allow  analysis  of  options  related  to  the  elimination  of  the  large 
event-driven  design  reviews  that  are  currently  part  NAVAIRs  acquisition  process.  This  alone 
has  the  potential  to  reduce  the  time  and  cost  to  acquire  systems  as  design  maturity  could  be 
verified  incrementally  as  the  system  was  developed  vice  waiting  for  specific  large  “big  bang” 
technical  reviews  where  the  whole  system  was  at  the  same  state  of  design.  This  highlights 
potential  sweeping  changes  to  the  current  business  process  to  capture  these  types  of 
efficiencies. 

Summary 

The  acquisition  process  has  made  changes  over  the  past  several  years,  most 
notably  the  implementation  of  performance  based  specifications  year  ago  (e.g.,  JCIDS 
process).  With  this  came  many  new  considerations  for  the  design  review  team  and  the 
advent  of  a  fairly  intrusive  overview  process.  This  process  was  implemented  with 
overdependence  upon  highly  experienced  government  workforce.  As  mission 
interoperability  and  system  complexities  have  increased,  new  concepts  such  as  IWC  are 
being  introduced.  These  methods  are  integration  responsibilities  of  the  government 
workforce,  coping  with  increased  complexity,  and  providing  innovative  ways  to  determine 
design  maturity  and  spec  compliance  become  increasingly  important.  The  numerous 
changes  to  the  DoD  5000  process  have  resulted  in  additional  oversight  requirements.  These 
oversight  mandates  have  modified  design  review  names  and  periodicity,  however,  have  not 
been  accompanied  with  repeatable  and  quantifiable  methods  to  evaluate  design  quality  and 
quantifiable  engineering  risk  reduction. 

The  above  changes  coupled  with  the  rapidly  accelerating  decrease  in  experience  in 
the  government  workforce  and  the  development  of  new  technologies,  computer  power,  and 
a  workforce  that  is  comfortable  in  that  environment,  the  time  is  right  to  further  develop  and 
implement  the  SDEA  concept  and  create  a  MBAF  that  will  provide  the  government  team  with 
the  ability  and  design  insight  that  is  required  to  do  what  they  are  expected  to  do.  Model- 
based  engineering  reviews  that  provide  repeatable,  data  driven  answers  will  help  ensure 
that  the  systems  the  government  procures  can  meet  the  needs  and  expectations  of  the 
warfighter  and,  performed  correctly  with  process  changes,  will  be  able  to  acquire  faster  and 
utilize  fewer  human  and  financial  resources.  MBAF  is  a  starting  point  to  investigate  and 
create  a  model-based  acquisition  system  that  can  make  the  acquisition  process  more 
dynamic  and  expeditious.  The  SDEA  process  will  create  a  system  definition  model-based 
start  for  the  program  that  will  enhance  the  programs  ability  to  communicate  with  the  IWC 
models  and  vendors  and  determine  with  much  more  clarity  its  requirements  and 
interoperability.  This  model  underpins  all  engineering  and  management  methods  and 
practices,  becomes  higher  fidelity  as  the  acquisition  progresses  through  the  MBAF 
framework,  and  the  technical  baseline  for  the  entire  lifecycle  of  the  system/program. 

The  last  consideration  for  implementation  of  a  MBAF  is  that  of  adjusting  the 
acquisition  process.  Currently  the  DoD  5000.02  prescribes  a  regimented,  document  and 
schedule  driven  process  on  which  NAVAIR  has  implemented  the  SETR  process.  The  SETR 
process  is  an  event-based  review  cycle  to  determine  required  design  maturity  levels.  As 
stated  earlier,  a  MBAF  should  allow  for  a  much  more  flexible  and  more  dynamic  insight  and 
review  process  that  should  highlight  areas  for  process  changes  to  capture  these  efficiencies. 
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DEVELOPMENT  COST  GROWTH 
BY  CATEGORY 


•  Problem  Motivation 

-  ACAT  I  -  12  years 

-  ACAT  II  -  8  years 

-  Lack  of  agility 

-  Schedule  driven 

-  Document  centric 
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Background 


Changes  at  NAVAIR 

-  Increased  emphasis  on  becoming  LSI 

•  Helicopter  program 

•  UAV  Program 

•  NextGen  Jammer  Program 

-  Mission  Driven  Acquisition 

•  Integrated  Warfare  Concept  (IWC) 

•  Mission  centric  approach  to  defining  operational 
requirements 

•  Using  MBSE 


Need  to  interface  POR  MBSE  to  IWC  MBSE 


Background  (cont) 


LSI,  SoS,  Models 
Operational  &  Mission  Reqmts 

IWC 

^  SDEA 
POR 


Workforce,  Tools,  Training 
Documents,  Process,  System  Reqmts 
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Problem  Statement 


Problem 

DoD  does  not  have  adequate  Systems  Engineering  (SE)  methods, 
processes,  workflows,  and/or  tools  that  support  the  expansive 
Governmental  role  of  the  LSI  in  major  weapons  systems 
acquisitions  or  the  ability  to  integrate  with  and  develop  the 
programs  of  record  identified  through  the  top-down  IWC  analysis 
process. 

•How  can  the  use  of  MBSE  tools  be  applied  to  aid  the  program  office  in 
assuming  more  of  the  LSI  role? 

•What  are  the  varied  SE  methods  and  practices  in  use  across  NAVAIR  today? 
•What  is  a  model  of  the  NAVAIR  acquisition  process  in  use  today? 

•What  is  an  integrated  framework  of  tools  and  MBSE  methods  that  reflects 
the  artifacts  needed  to  integrate  with  the  IWC  and  perform  LSI  roles? 

•How  can  this  new  Model  Based  Acquisition  Framework  (MBAF)  be  applied  to 
simulate  or  optimize  process  variations  on  programs? 


SE  LSI  Skills 


Conduct  analysis  of  broad  system  requirements  and  identify  inter¬ 
dependencies 

Perform  the  SoS  LSI  role  and  deriving  trade  space  to  be  held  at 
mission  level 

Ensuring  SoS  optimization  and  cross  platform  interoperability  that 
provide  traceability  to  mission  level  requirements. 

Define  and  control  system  interfaces  consistent  with  the  overall 
systems  architecture  -  both  in  the  SoS  operational  architecture,  and  in 
the  related  SoS  views  -  to  ensure  required  Mission  level  capability  is 
delivered  through  deliberate  system  development  as  part  of  required 
SoS  functionality. 

Develop  the  System  Architecture  must  be  developed  by  the 
Government  (may  not  be  outsourced)  and  also  done  without 
contracting  for  support  with  the  Prime  contractor  or  any  major 
subsystem  vendor.  Government  ownership  of  system-level 
architectures  reduces  possibility  of  proprietary  or  non-compliant 
contractor-specific  architectures 

Control  the  technical  trade  space  rougl  preliminary  design  to 
include  budget,  requirements  and  schedule  tradeoffs 
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PM  LSI  skills 


Developing  project  schedules  and  resource  estimates  across  multi- 
disciplined  technical  teams. 

Establishing  and  managing  broad  system  processes  that  align 
requirements  and  interdependencies  across  program  boundaries. 
Controlling  the  trade  space  through  preliminary  design  to  include 

budget,  requirements  and  schedule  tradeoffs 

Maintaining  traceability  of  systems  integration  requirements  to  higher 
level  mission  objectives. 

Representing  the  system  command  at  national  technical  reviews 
Exercising  technical  authority.  Government  is  the  integrator  of  major 
subsystems  in  the  architecture  as  part  of  performing  the  LSI  role. 
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Current  Tools/Methodology 
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Pockets  of  work  ongoing 
No  Consistent  Application 
Many  Tools  Available 
UML/SysML/DoDAF  ^ 
Data  Models 
Physical  Models 
Domain  Specific 
Languages  (DSL) 


(Derived  from  Estefan,  2008) 
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Proposed  Methodology 


•  Develop  a  model-based  system  that  could  replace  the  current 
document,  event-driven  system  that  would  add  clarity  to  the 
design  as  it  matured  and  would  lead  to  the  reduction  in  total 
acquisition  time. 

•  Would  allow  engineers  to  “see”  that  the  system  meets  their 
requirements  would  also  be  able  to  demonstrate  that  it  would 
work. 

•  Data-driven  approach  would  result  in  a  model  of  the  designed 
system  that  could  be  utilized  for  changes  during  development  as 
well  as  system  modifications  after  deployment,  which  would  be 
an  additional  time  savings  over  the  total  lifecycle. 

•  Ability  to  look  up  into  the  IWC  and  the  operational  requirements 
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Approach 


*  Create  a  Model  Based  Acquisition  Framework 


MBAF 


|  Model  Based  Acquisition  Framework 
1  1  = 


SDEA 

BPM 

System  Definition  Enabled  Acquisition 

Business  Process  Model 

MDD  ■  MBSE  ■  MBSI  ■  Model  IProcess 


^^Model  Based  SE  ^^Mode^asedsF  ^^Do^500^| 


MBSI 


Identify  the  artifacts  needed  and  the  tools 
available  to  produce  the  artifacts  needed 
to  perform  Technical  reviews 
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System  Definition  Enabled  Acquisition 


*  Initial  Components  of  SDEA 


(Montgomery,  Carlson  2013) 


Clearly  defines  and  illustrates  the  requirements  and  CONOPS  in  a 
form  that  “shall”  statements  alone  cannot 
Initial  Architecture  is  functional,  data  driven  linkage  of  the 
requirements  and  CONOPS 
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Progress  to  date 


•  Data  driven  Model  of  NAVAIRs  current 

acquisition  procedure,  the  DOD  5000.02 

-  NAVAIR  Systems  Engineering  Technical 
Review  process 

•  300  artifacts  reduced  to  134  System  Engineering 
artifacts 


Acquisition 

Milestones' 

Phases 


Products  O 

Acquisition 
Gate  | 
Reviews  *— 


Concept  Development  & 

Validation 

Design  Development  & 

Validation 

Produce  &Qualify 

Deploy  &  Improve 


(Derived  from  DoD  5000) 
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Notations 


•  CORE*  as  the  modeling  tool 


-  Items  - 

-  Functions- 

-  Components- 

-  Interfaces  - 

-  Packages  - 


SETR  artifacts 

SE  Process  steps  or  Engineering  activities 
Acquisition  Phases  (DoD  500.02) 
Engineering  Documents 
Tools  in  use  today  that  create  artifacts 


•  Process  definition  from 

-  ISO  15288 

-  Navy  Systems  Engineering  Guide 

*Vitech  Corp.  CORE  MBSE  tool 
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Results  to  Date 


•  Developing  CORE  Model  of  as-is  Acquisition  Process 

•  Focused  on  program  initiation  through  Preliminary  Design 

•  145  Functions  or  Process  steps 


•  135  Items  or  Artifacts 
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Conclusions/Future  Research 


Detailed  artifacts  required  to  satisfy  NAVAIR  design  reviews 

Insight  into  why  artifacts  are  produced,  what  design  question  do  they  answer 

List  of  current  tools  that  are  used  to  produce  artifacts 

Artifacts  required  by  design  phase 

Artifacts-Reason-Phase-Tool  =  MBAF 

Revolutionize  the  NAVAIR  SETR  process 


System  Engineering  & 
Design 

Interfaces 

Operations 

Architecture 

Qualification 

Risk 


TOC  Analysis 


Qualification 


System  Engineering  & 
Acquisition 


SETRs 


Trade  Studies 


LSI/SoS 


Management 


Model  &  Sim 


i^. 


■V.  «  /  ippHWHI  s 


Baseline  Mgmt 
P3I 


(Montgomery,  Carlson  2012) 
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